1
2
Siguiente
No.
El JSON es solo de datos, y si incluye un comentario, también serán datos.
Podría tener un elemento de datos designado llamado "_comment" (o algo así) que las aplicaciones que usan los datos JSON deberían ignorar.
Probablemente sería mejor tener el comentario en los procesos que genera / recibe el JSON, ya que se supone que deben saber cuáles serán los datos JSON de antemano, o al menos la estructura de los mismos.
Pero si decidiste:
{
"_comment": "el texto del comentario va aquí ...",
"glosario": {
"title": "glosario de ejemplo",
"GlossDiv": {
"título": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"Ordenar como": "SGML",
"GlossTerm": "Lenguaje de marcado generalizado estándar",
"Acrónimo": "SGML",
"Abrev": "ISO 8879: 1986",
"GlossDef": {
"para": "Un lenguaje de metamarcado, utilizado para crear lenguajes de marcado como DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "marcado"
}
}
}
}
}
|
No, los comentarios de la forma //… o / *… * / no están permitidos en JSON. Esta respuesta se basa en:
https://www.json.org
RFC 4627:
La aplicación / json Media Type para JavaScript Object Notation (JSON)
RFC 8259 El formato de intercambio de datos de notación de objetos JavaScript (JSON) (reemplaza a las RFC 4627, 7158, 7159)
|
Incluya comentarios si lo desea; quítelos con un minificador antes de analizarlos o transmitirlos.
Acabo de publicar JSON.minify () que elimina los comentarios y los espacios en blanco de un bloque de JSON y lo convierte en un JSON válido que se puede analizar. Entonces, podrías usarlo como:
JSON.parse (JSON.minify (my_str));
Cuando lo publiqué, recibí una gran reacción de personas que no estaban de acuerdo incluso con la idea, así que decidí escribir una publicación de blog completa sobre por qué los comentarios tienen sentido en JSON. Incluye este notable comentario del creador de JSON:
Suponga que está usando JSON para mantener los archivos de configuración que le gustaría anotar. Adelante, inserta todos los comentarios que te gusten. Luego, canalícelo a través de JSMin antes de entregarlo a su analizador JSON. - Douglas Crockford, 2012
Con suerte, eso es útil para aquellos que no están de acuerdo con por qué JSON.minify () podría ser útil.
|
Los comentarios se eliminaron de JSON por diseño.
Eliminé los comentarios de JSON porque vi que las personas los usaban para mantener directivas de análisis, una práctica que habría destruido la interoperabilidad. Sé que la falta de comentarios entristece a algunas personas, pero no debería ser así.
Suponga que está usando JSON para mantener los archivos de configuración que le gustaría anotar. Adelante, inserta todos los comentarios que te gusten. Luego, canalícelo a través de JSMin antes de entregarlo a su analizador JSON.
Fuente: Declaración pública de Douglas Crockford sobre G +
|
JSON no admite comentarios. Tampoco se diseñó para usarse en archivos de configuración donde se necesitarían comentarios.
Hjson es un formato de archivo de configuración para humanos. Sintaxis relajada, menos errores, más comentarios.
Consulte hjson.github.io para las bibliotecas JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ y C #.
|
DESCARGO DE RESPONSABILIDAD: SU GARANTÍA ES ANULADA
Como se ha señalado, este truco aprovecha la implementación de la especificación. No todos los analizadores JSON entenderán este tipo de JSON. En particular, los analizadores de flujo se ahogarán.
Es una curiosidad interesante, pero realmente no deberías usarla para nada. A continuación se muestra la respuesta original.
Encontré un pequeño truco que le permite colocar comentarios en un archivo JSON que no afectará el análisis ni alterará los datos que se representan de ninguna manera.
Parece que al declarar un objeto literal se pueden especificar dos valores con la misma clave, y el último tiene prioridad. Lo crea o no, resulta que los analizadores JSON funcionan de la misma manera. Entonces, podemos usar esto para crear comentarios en el JSON de origen que no estarán presentes en una representación de objeto analizado.
({a: 1, a: 2});
// => Objeto {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Length;
// => 1
Si aplicamos esta técnica, su archivo JSON comentado podría verse así:
{
"api_host": "El nombre de host de su servidor API. También puede especificar el puerto.",
"api_host": "hodorhodor.com",
"retry_interval": "El intervalo en segundos entre reintentos de llamadas a API fallidas",
"retry_interval": 10,
"auth_token": "El token de autenticación. Está disponible en tu panel de desarrollador en 'Configuración'",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": "Una matriz que contiene mis números favoritos de todos los tiempos",
"números_de_secretos": [19, 13, 53]
}
El código anterior es JSON válido. Si lo analiza, obtendrá un objeto como este:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"números_de_secretos": [19,13,53]
}
Lo que significa que no hay rastro de los comentarios y no tendrán efectos secundarios extraños.
¡Feliz piratería!
|
Considere usar YAML. Es casi un superconjunto de JSON (prácticamente todo JSON válido es YAML válido) y permite comentarios.
|
No puedes. Al menos esa es mi experiencia de un vistazo rápido a json.org.
JSON tiene su sintaxisvisualizado en esa página. No hay ninguna nota sobre comentarios.
|
Los comentarios no son un estándar oficial, aunque algunos analizadores admiten comentarios de estilo C ++. Uno que uso es JsonCpp. En los ejemplos hay este:
// Opciones de configuración
{
// Codificación predeterminada para texto
"codificación": "UTF-8",
// Complementos cargados al inicio
"complementos": [
"pitón",
"c ++",
"rubí"
],
// Tamaño de sangría de tabulación
"indent": {"length": 3, "use_space": true}
}
jsonlint no valida esto. Por lo tanto, los comentarios son una extensión específica del analizador y no estándar.
Otro analizador es JSON5.
Una alternativa a JSON TOML.
Otra alternativa es jsonc.
La última versión de nlohmann / json tiene soporte opcional para ignorar los comentarios sobre el análisis.
|
En su lugar, debería escribir un esquema JSON. El esquema JSON es actualmente un borrador de especificación propuesto para Internet. Además de la documentación, el esquema también se puede utilizar para validar sus datos JSON.
Ejemplo:
{
"description": "Una persona",
"tipo": "objeto",
"propiedades":
{
"nombre":
{
"tipo": "cadena"
},
"años":
{
"tipo": "entero",
"máximo": 125
}
}
}
Puede proporcionar documentación utilizando el atributo de esquema de descripción.
|
Si está utilizando Jackson como su analizador JSON, así es como lo habilita para permitir comentarios:
Mapeador de ObjectMapper = new ObjectMapper (). Configure (Feature.ALLOW_COMMENTS, verdadero);
Entonces puedes tener comentarios como este:
{
clave: "valor" // Comentario
}
Y también puede tener comentarios que comiencen con # configurando:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, verdadero);
Pero en general (como se respondió antes) la especificación no permite comentarios.
|
Esto es lo que encontré en la documentación de Google Firebase que le permite poner comentarios en JSON:
{
"//": "Algunos navegadores lo utilizarán para habilitar las notificaciones push.",
"//": "Es igual para todos los proyectos, este no es el ID de remitente de su proyecto",
"gcm_sender_id": "1234567890"
}
|
NO. JSON solía admitir comentarios, pero se abusó de ellos y se eliminaron del estándar.
Del creador de JSON:
Eliminé los comentarios de JSON porque vi que las personas los usaban para mantener directivas de análisis, una práctica que habría destruido la interoperabilidad. Sé que la falta de comentarios entristece a algunas personas, pero no debería ser así. - Douglas Crockford, 2012
El sitio JSON oficial está en JSON.org. JSON está definido como estándar por ECMA International. Siempre hay un proceso de petición para que se revisen los estándares. Es poco probable que se agreguen anotaciones al estándar JSON por varias razones.
JSON por diseño es una alternativa fácil de ingeniería inversa (analizada por humanos) a XML. Se simplifica incluso hasta el punto de que las anotaciones son innecesarias. Ni siquiera es un lenguaje de marcado. El objetivo es la estabilidad y la interoperabilidad.
Cualquiera que entienda la relación "tiene-a" de la orientación a objetos puede entender cualquier estructura JSON - ese es el punto. Es solo un gráfico acíclico dirigido (DAG) con etiquetas de nodo (pares clave / valor), que es una estructura de datos casi universal.
Esta única anotación necesaria podría ser "// Estas son etiquetas DAG". Los nombres de las claves pueden ser tan informativos como sea necesario, lo que permite una aridad semántica arbitraria.
Cualquier plataforma puede analizar JSON con solo unas pocas líneas de código. XML requiere bibliotecas OO complejas que no son viables en muchas plataformas.
Las anotaciones solo harían que JSON sea menos interoperable. Simplemente no hay nada más que agregar, a menos que lo que realmente necesite sea un lenguaje de marcado (XML), y no le importe si sus datos persistentes se pueden analizar fácilmente.
PERO, como también observó el creador de JSON, siempre ha habido soporte de canalización JS para comentarios:
Adelante, inserta todos los comentarios que te gusten.
Luego, canalícelo a través de JSMin antes de entregarlo a su analizador JSON. - Douglas Crockford, 2012
|
Si su archivo de texto, que es una cadena JSON, va a ser leído por algún programa, ¿qué tan difícil sería eliminar los comentarios de estilo C o C ++ antes de usarlo?
Respuesta: Sería una sola línea. Si lo hace, los archivos JSON podrían usarse como archivos de configuración.
|
Si está utilizando la biblioteca Newtonsoft.Json con ASP.NET para leer / deserializar, puede usar comentarios en el contenido JSON:
// "nombre": "cadena"
//"Yo dint
o
/* Esto es un
ejemplo de comentario * /
PD: Los comentarios de una sola línea solo son compatibles con más de 6 versiones de Newtonsoft Json.
Nota adicional para las personas que no pueden pensar fuera de la caja: uso el formato JSON para la configuración básica en una aplicación web ASP.NET que hice. Leo el archivo, lo convierto en el objeto de configuración con la biblioteca Newtonsoft y lo uso cuando es necesario.
Prefiero escribir comentarios sobre cada configuración individual en el archivo JSON en sí, y realmente no me importa la integridad del formato JSON siempre que la biblioteca que uso esté bien.
Creo que esta es una forma 'más fácil de usar / entender' que crear un archivo 'settings.README' separado y explicar la configuración en él.
Si tiene algún problema con este tipo de uso; lo siento, el genio está fuera de la lámpara. La gente encontraría otros usos paraFormato JSON, y no hay nada que pueda hacer al respecto.
|
La idea detrás de JSON es proporcionar un intercambio de datos simple entre aplicaciones. Suelen estar basados en la web y el idioma es JavaScript.
Realmente no permite comentarios como tales, sin embargo, pasar un comentario como uno de los pares de nombre / valor en los datos ciertamente funcionaría, aunque esos datos obviamente tendrían que ser ignorados o manejados específicamente por el código de análisis.
Dicho todo esto, no es la intención que el archivo JSON contenga comentarios en el sentido tradicional. Deberían ser solo los datos.
Eche un vistazo al sitio web JSON para obtener más detalles.
|
JSON no admite comentarios de forma nativa, pero puedes crear tu propio decodificador o al menos un preprocesador para eliminar los comentarios, eso está perfectamente bien (siempre que ignores los comentarios y no los uses para guiar cómo tu aplicación debe procesar los datos JSON ).
JSON no tiene comentarios. Un codificador JSON NO DEBE generar comentarios.
Un decodificador JSON PUEDE aceptar e ignorar comentarios.
Los comentarios nunca deben usarse para transmitir algo significativo. Es decir
para qué sirve JSON.
Cf: Douglas Crockford, autor de JSON spec.
|
Acabo de encontrar esto para los archivos de configuración. No quiero usar XML (detallado, gráficamente, feo, difícil de leer) o formato "ini" (sin jerarquía, sin estándar real, etc.) o formato de "Propiedades" de Java (como .ini).
JSON puede hacer todo lo posible, pero es mucho menos detallado y más legible por humanos, y los analizadores son fáciles y ubicuos en muchos idiomas. Es solo un árbol de datos. Pero los comentarios fuera de banda son a menudo una necesidad para documentar configuraciones "predeterminadas" y similares. Las configuraciones nunca deben ser "documentos completos", sino árboles de datos guardados que pueden ser legibles por humanos cuando sea necesario.
Supongo que se podría usar "#": "comentario", para JSON "válido".
|
Depende de su biblioteca JSON. Json.NET admite comentarios de estilo JavaScript, / * commment * /.
Consulte otra pregunta de Stack Overflow.
|
JSON tiene mucho sentido para los archivos de configuración y otros usos locales porque es ubicuo y porque es mucho más simple que XML.
Si las personas tienen fuertes razones para no tener comentarios en JSON al comunicar datos (sean válidos o no), entonces posiblemente JSON podría dividirse en dos:
JSON-COM: JSON en el cable o reglas que se aplican al comunicar datos JSON.
JSON-DOC: documento JSON o JSON en archivos o localmente. Reglas que definen un documento JSON válido.
JSON-DOC permitirá comentarios y pueden existir otras diferencias menores, como el manejo de espacios en blanco. Los analizadores pueden convertir fácilmente de una especificación a otra.
Con respecto al comentario de Douglas Crockford sobre este tema (referenciado por @Artur Czajka)
Suponga que está usando JSON para mantener los archivos de configuración que le gustaría anotar. Adelante, inserta todos los comentarios que te gusten. Luego, canalícelo a través de JSMin antes de entregarlo a su analizador JSON.
Estamos hablando de un problema de archivo de configuración genérico (lenguaje cruzado / plataforma), ¡y está respondiendo con una utilidad específica de JS!
Seguro que un minify específico de JSON se puede implementar en cualquier idioma,
pero estandarice esto para que se vuelva omnipresente en todos los analizadores en todos los idiomas y plataformas para que la gente deje de perder el tiempo sin la función porque tienen buenos casos de uso para ella, buscan el problema en foros en línea y hacen que la gente les diga que es una mala idea o sugiriendo que es fácil implementar la eliminación de comentarios de los archivos de texto.
El otro problema es la interoperabilidad. Suponga que tiene una biblioteca o API o cualquier tipo de subsistema que tiene algunos archivos de configuración o datos asociados. Y este subsistema es
para acceder desde diferentes idiomas. Entonces le dices a la gente: por cierto
¡No olvide eliminar los comentarios de los archivos JSON antes de pasarlos al analizador!
|
Si usa JSON5, puede incluir comentarios.
JSON5 es una extensión propuesta para JSON que tiene como objetivo facilitar a los humanos la escritura y el mantenimiento a mano. Lo hace agregando algunas características de sintaxis mínima directamente desde ECMAScript 5.
|
El kit de herramientas de JavaScript de Dojo Toolkit (al menos a partir de la versión 1.4) le permite incluir comentarios en su JSON. Los comentarios pueden tener el formato / * * /. Dojo Toolkit consume JSON a través de la llamada dojo.xhrGet ().
Otros conjuntos de herramientas de JavaScript pueden funcionar de manera similar.
Esto puede ser útil al experimentar con estructuras de datos alternativas (o incluso listas de datos) antes de elegir una opción final.
|
JSON no es un protocolo enmarcado. Es un formato libre de idiomas. Entonces, el formato de un comentario no está definido para JSON.
Como han sugerido muchas personas, existen algunos trucos, por ejemplo, claves duplicadas o un _comentario de clave específico que puede utilizar. Tu decides.
|
Puede tener comentarios en JSONP, pero no en JSON puro. Acabo de pasar una hora tratando de hacer que mi programa funcione con este ejemplo de Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Si sigue el enlace, verá
? (/ * AAPLdatos históricos de OHLC de la API de Google Finance * /
[
/ * Mayo de 2006 * /
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);
Como tenía un archivo similar en mi carpeta local, no hubo problemas con la política del mismo origen, así que decidí usar JSON puro ... y, por supuesto, $ .getJSON estaba fallando silenciosamente debido a los comentarios.
Finalmente, envié una solicitud HTTP manual a la dirección anterior y me di cuenta de que el tipo de contenido era texto / javascript ya que, bueno, JSONP devuelve JavaScript puro. En este caso, se permiten comentarios. Pero mi aplicación devolvió application / json de tipo de contenido, por lo que tuve que eliminar los comentarios.
|
Esta es una pregunta "¿puedes?". Y aquí hay una respuesta "sí".
No, no debe usar miembros de objeto duplicados para rellenar datos de canal lateral en una codificación JSON. (Consulte "Los nombres dentro de un objeto DEBEN ser únicos" en el RFC).
Y sí, podría insertar comentarios alrededor del JSON, que podría analizar.
Pero si desea una forma de insertar y extraer datos de canal lateral arbitrarios en un JSON válido, aquí tiene una respuesta. Aprovechamos la representación no única de datos en una codificación JSON. Esto está permitido * en la sección dos del RFC bajo "Se permiten espacios en blanco antes o después de cualquiera de los seis caracteres estructurales".
* El RFC solo establece que "se permiten espacios en blanco antes o después de cualquiera de los seis caracteres estructurales", sin mencionar explícitamente cadenas, números, "falso", "verdadero" y "nulo". Esta omisión se ignora en TODAS las implementaciones.
Primero, canonicaliza tu JSON minificándolo:
$ jsonMin = json_encode (json_decode ($ json));
Luego codifique su comentario en binario:
$ hex = desempaquetar ('H *', $ comentario);
$ commentBinary = conversión_base ($ hex [1], 16, 2);
Luego, configure su binario:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Aquí está su salida:
$ jsonWithComment = $ steg. $ jsonMin;
|
Descargo de responsabilidad: esto es una tontería
En realidad, hay una forma de agregar comentarios y permanecer dentro de la especificación (no se necesita un analizador adicional). Sin embargo, no resultará en comentarios legibles por humanos sin ningún tipo de análisis.
Podría abusar de lo siguiente:
Se permiten espacios en blanco insignificantes antes o después de cualquier ficha.
El espacio en blanco es cualquier secuencia de uno o más de los siguientes códigos
puntos: tabulación de caracteres (U + 0009), salto de línea (U + 000A), carro
return (U + 000D) y espacio (U + 0020).
De una manera hacky, puedes abusar de esto para agregar un comentario. Por ejemplo: comience y termine su comentario con una pestaña. Codifique el comentario en base3 y use los otros espacios en blanco para representarlos. Por ejemplo.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(hola base tres en ASCII) Pero en lugar de 0 use espacio, para 1 use salto de línea y para 2 use retorno de carro.
Esto solo te dejará con una gran cantidad de espacios en blanco ilegibles (a menos que crees un complemento IDE para codificarlo / decodificarlo sobre la marcha).
Ni siquiera intenté esto, por razones obvias y tú tampoco deberías.
|
JSON no permite comentarios, per se. El razonamiento es completamente tonto, porque puede usar JSON en sí mismo para crear comentarios, lo que obvia el razonamiento por completo y carga el espacio de datos del analizador sin una buena razón para exactamente el mismo resultado y problemas potenciales, como son: un JSON archivo con comentarios.
Si intenta poner comentarios (usando // o / * * / o # por ejemplo), algunos analizadores fallarán porque esto no es estrictamente
dentro de la especificación JSON. Así que nunca deberías hacer eso.
Aquí, por ejemplo, donde mi sistema de manipulación de imágenes ha guardado notaciones de imágenes y alguna información básica formateada (comentario) relacionada con ellas (en la parte inferior):
{
"Notaciones": [
{
"anchorX": 333,
"anchorY": 265,
"areaMode": "Elipse",
"extensiónX": 356,
"extensiónY": 294,
"opacidad": 0,5,
"text": "Área elíptica en la parte superior",
"textX": 333,
"textY": 265,
"title": "Notación 1"
},
{
"anchorX": 87,
"anchorY": 385,
"areaMode": "Rectángulo",
"extensiónX": 109,
"extensiónY": 412,
"opacidad": 0,5,
"text": "Rect area \ non bottom",
"textX": 98,
"textY": 385,
"title": "Notación 2"
},
{
"anchorX": 69,
"anchorY": 104,
"areaMode": "Polígono",
"extensiónX": 102,
"extensiónY": 136,
"opacidad": 0,5,
"pointList": [
{
"yo": 0,
"x": 83,
"y": 104
},
{
"yo": 1,
"x": 69,
"y": 136
},
{
"yo": 2,
"x": 102,
"y": 132
},
{
"yo": 3,
"x": 83,
"y": 104
}
],
"text": "Polígono simple",
"textoX": 85,
"textY": 104,
"title": "Notación 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "Datos de notación de imagen JSON:",
"c02": "-------------------------",
"c03": "",
"c04": "Estos datos contienen notaciones de imágenes y áreas relacionadas",
"c05": "información de selección que proporciona un medio para",
"c06": "galería de imágenes para mostrar notaciones con elíptica",
"c07": "indicaciones de área rectangular, poligonal o a mano alzada",
"c08": "sobre una imagen que se muestra a un visitante de la galería",
"c09": "",
"c10": "Las posiciones X e Y están todas en la imagenespacio. La imagen",
"c11": "la resolución se da como imageXW e imageYW, que",
"c12": "se usa para escalar las áreas de notación a su debido tiempo",
"c13": "ubicaciones y tamaños para la visualización de la imagen",
"c14": "independientemente de la escala",
"c15": "",
"c16": "Para elipses, el ancla es el centro de la elipse",
"c17": "y las extensiones son los radios X e Y respectivamente.",
"c18": "",
"c19": "Para rectángulos, el ancla es la parte superior izquierda y el",
"c20": "las extensiones son la parte inferior derecha.",
"c21": "",
"c22": "Para los modos de área Mano alzada y Polígono, la lista de puntos",
"c23": "contiene una serie de puntos XY numerados. Si el área",
"c24": "está cerrado, el último punto será el mismo que el",
"c25": "primero, así que todo lo que tienes que preocuparte es dibujar",
"c26": "líneas entre los puntos de la lista. Anclaje y extensión",
"c27": "se establecen en la parte superior izquierda e inferior derecha de la indicada",
"c28": "región, y se puede utilizar como un rectángulo simplista",
"c29": "detecta la posición del mouse sobre estos tipos",
"c30": "de áreas.",
"c31": "",
"c32": "Las posiciones textx y texty proporcionan un posicionamiento básico",
"c33": "información que le ayudará a localizar la información del texto",
"c34": "en una ubicación razonable asociada con el área",
"c35": "indicación.",
"c36": "",
"c37": "La opacidad es un valor entre 0 y 1, donde .5 representa",
"c38": "un fondo 50% opaco y 1.0 representa un fondo completamente opaco",
"c39": "telón de fondo. La recomendación es que se dibujen las regiones",
"c40": "solo si el usuario pasa el puntero sobre la imagen,",
"c41": "y que se dibuje el texto asociado a las regiones",
"c42": "solo si el usuario pasa el puntero sobre el indicado",
"c43": "región".
}
}
|
Estamos usando strip-json-comments para nuestro proyecto. Es compatible con algo como:
/ *
* Descripcion
* /
{
// arcoiris
"unicornio": / * ❤ * / "pastel"
}
Simplemente npm install --save strip-json-comments para instalarlo y usarlo como:
var strip_json_comments = require ('strip-json-comments')
var json = '{/ * arcoíris * / "unicornio": "pastel"}';
JSON.parse (strip_json_comments (json));
// => {unicornio: 'pastel'}
|
En mi caso, necesito usar comentarios con fines de depuración justo antes de la salida de la estructura JSON. Así que decidí usar información de depuración en el encabezado HTTP para evitar romper el cliente:
header ("My-Json-Comment: Sí, sé que es una solución alternativa ;-)");
|
Para cortar un elemento JSON en partes, agrego líneas de "comentario ficticio":
{
"#############################" : "Parte 1",
"datos1": "valor1",
"datos2": "valor2",
"#############################" : "Parte 2",
"datos4": "valor3",
"datos3": "valor4"
}
|
1
2
Siguiente
Pregunta muy activa. Gana 10 de reputación para responder a esta pregunta. El requisito de reputación ayuda a proteger esta pregunta del spam y de la actividad sin respuesta.
No es la respuesta que estás buscando? Lea otras preguntas etiquetadas como comentarios json o haga su propia pregunta.